Vehicles today have hundreds of sensors and actuators designed to provide safe, reliable, convenient and comfortable transportation. Each of these devices interfaces with one of dozens of computer modules designed for data integration and processing. These computers control powertrain operation, chassis integration, infotainment, and additional vehicle functionality through complex programs that are exceedingly difficult targets for software development.
This complexity can lead to several problems. In cases, software is released to the public in the beta stage of development to meet shipping deadlines. Features may be added later to improve competitiveness across brands, or bugs may be discovered that compromise comfort or safety. Modern automotive computers are extremely complicated, yet a small software bug can result in severe safety issues possibly resulting in federal recalls. Technology exists today capable of remotely updating vehicle software. However, due to rigorous checksum validation, these software updates may take several hours to complete, during which the vehicle is unusable for risk of rendering a control module inoperative. Specifically, if a vehicle is powered on during the updating of vehicle software, the use of the vehicle may interrupt the upgrade process and thereby render a control module of the vehicle inoperative temporarily or permanently. For purposes of clarity, powering on means activated, or if a vehicle key switch commands power to a module or modules of the vehicle.
Typically, modules in vehicles “phone home” or are pushed details about software update candidates via a telemetry unit. These updates may download overnight, or even provide feedback on an in-vehicle display informing the user that their software is being upgraded and not to change the operating state of the vehicle until the update event is complete. This can work, but in some cases, the software updates happen at inopportune times and users intervene necessitating the programming event be redone, if the module firmware does not become corrupted upon the loss of power. This is presently a problem, as automobile manufacturers face a constant struggle determining tradeoffs in acceptable latency and power consumption, and often elect to install software as soon as the download is complete, irrespective of driver needs.
Certain automobile manufacturers confronted with the difficulty of upgrading software resort to recalling vehicles, thereby requiring vehicle owners to lose valuable time and causing a great deal of man hours in non-billable labor. Even in the situation where a fail-safe downloading program is used, interruption of the downloading program will not cause crashing of a module performing the upgrade, however, it will prevent the software update from taking place and requires that the time consuming process be restarted.
There has been some discussion regarding over the air updates recently as a solution to this problem. In the few cases where a manufacturer remotely updates vehicle software, as is the case with Mercedes' mBrace 2 system, these updates impact infotainment applications and not control module software. The primary reason control modules are not presently updated is the result of the highly complex software inherent to these core systems. As criticality and integration increase, so increases the file size of any related software update. These files are large, transfer slowly due to bandwidth constraints, and must continuously undergo checksum validation to ensure that mission-critical software is not corrupted. This same rigorous software analysis occurs during module reflashing events, ensuring that the update is correct on a byte-per-byte basis. The end result is an update process that often takes several hours, even when dealing with relatively small files like a ten-megabyte engine control software update.
The issue of slow downloads has been addressed through the use of higher-throughput networks and with the use of smart telematics systems, on-board storage and extra flash memory internal to these modules for storing software images in a temporary holding buffer. Despite this reduction in barrier to entry, over the air upgrades remain unlikely to be adopted due to the long installation time during which a user cannot operate the vehicle without fear of corrupting the software on various modules. Hardware redundancy increases cost and complexity of these modules and time to market is long.
This upgrade difficulty is not limited to vehicles, but instead is experienced in upgrading software of any device or system such as, but not limited to, cellular telephones, battery management systems, appliances such as smart refrigerators, entertainment devices such as smart televisions or game consoles, personal computing devices (for instance, updating of the operating system of a computer), and farm/industrial equipment.
Thus, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.